1. Field
This disclosure relates to policy systems, more particularly to policy systems using Remote Access Dial-In User Services (RADIUS).
2. Background
Policy systems are typically a server or servers deployed in conjunction with a wholesale network to monitor and control traffic on the network in accordance with various policies. Policies that may impact the traffic control include service level agreements between wholesalers and their customers, and port management policies. The policy system generally enforces policies to ensure that the network is operating within pre-defined limits. At the core of policy enforcement is the establishment, enforcement and reporting of policy that affects a particular call.
RADIUS provides a means to monitor and control services across the wholesale dial, Voice over Internet Protocol (VoIP), and Any Service Any Port (ASAP) networks. The parameters and protocols for RADIUS messaging is set forth in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2865. One aspect of RADIUS is a pre-authentication request and response that allows the network to accept or reject messages prior to commitment of resources, such as by reservation. This increases network efficiency, as the resources are not committed while waiting for a policy system to accept or reject a call.
A problem that arises is when a pre-authentication request is rejected. This is generally accomplished in RADIUS using an “Access Reject” message. Under the terms of the IEFT's RFC 2865, the Access Reject message only needs to contain a text message that gives some indication of the reason for call rejection. This message is not well defined and may only be sent to the remote client that had the call rejected. This is not helpful for a policy system that has policy processors, gateways and accounting systems on separate hosts.
Similarly, there is no requirement that the RADIUS client receiving the Access Reject message as part of a pre-authentication transaction issue any form of accounting information. Remote reporting systems that should report on every call rejection have no guaranteed means to receiving accounting information for policy rejection criteria.
For calls that are accepted, there is no current way to indicate under which policies the call was accepted. Further there are no current means by which an accepted call is identified with a ‘standard use’ policy, or whether the call is part of an ‘over-subscription’ pool for which the customer is charged a premium.